The requirement specification was done with several different methods, each of them are documented and discussed in this section.
The result of these methods will also be included after the discussion.
\\\\
The tracing of specification technique of each requirement can be seen at each requirement in the All entities list.

\subsection{Context diagram}
Through discussion with the product owners and with an experienced application developer a context diagram was constructed. 
The system's relationship with other actors in the domain were described and later specified by listing how they communicate with each other.
Using this method the product owners got a clear picture about how their product will interact with other actors in its domain and makes it easier to see requirements that are connected to the product's interfaces.

	\begin{figure}[h!] \label{contextDiagram}
		\begin{center}
			\resizebox{!}{50mm}{\includegraphics{context.png}}
		\end{center}
	\end{figure}

The context diagram helped us specify for example the database requirements and developer contact.

\subsection{Feature requirements}
Through interviews with the product owners and validation of requirements from the elicitation process a list of features the system will include could be made.
The list contains the features that are required to be included in the product. Some were discarded but are still included in the document marked as dropped.

\begin{itemize}
 \item	The system shall be able to locate where the user is.
 \item	The system shall be able to change the center of the search radius.
 \item	The system shall support the user bookmarking POIs.
 \item	The system shall support the user blacklisting POIs. (dropped)
 \item	The system shall be able to filter search results based on radius, bookmarks, open hours, categories(dropped) and ratings(dropped).
 \item	The system shall allow for the user to toggle visibility on the filter radius. (dropped)
 \item	The system shall be able to share POIs to other users using SMS, mail and social medias.
 \item	The system shall be able to show directions from the user to a selected POI.
 \item	The system shall be able to show distance from the user to a POI in the form of travel time.
 \item	The system shall be able to create calendar events. (dropped)
 \item	The system shall be able to remove specific pins. (dropped)
 \item	The system shall be able to show a map view.
 \item	The system shall support panning a map view.
 \item	The system shall be able to create a preview for a POI. (dropped)
 \item	The system shall be ale to show information about a selected POI.
 \item	The system shall show direction arrows pointing to the closest POIs that transforms to a pin when the users gets close enough.
 \item	The system shall be able provide statistics on application usage for the customer and product owners.
 \item	The system shall include a tutorial starting at the application startup. (dropped)
 \item	The system shall be able to send development request to the developer team.
 \item	The system shall be able to send error messages to the development team.
 \item	The system shall remind the user to rate the application on app store/android market.
 \item	The system shall notify the user when a new release is available.
 \item	The system shall support the customer showing news to the user.
 \item	The system shall support the customer giving the user special offers in the form of coupons.
 \item	The system shall support a about view where information about the developers team and the application is posted.
 \item	The system shall show error messages when features malfunction.
 \item	The system shall allow for users to hide coupons.
 \item	The system shall be able to abort fetching POIs.
 \item	The system shall be cuztomizable for both user and the company.
 \item	The system shall be able to run on iOS.
 \item	The system shall be able to run on Android OS.
 \item	The system shall provide protection against buffer overflow and database injection attacks.
 \item	The system shall provide the user with a EULA at the first startup including EULAs for the APIs used to create the application.
\end{itemize}


\subsection{Task description}
With the help of information of the system derived from the requirements various tasks were agreed on. Those tasks were then described as task descriptions by describing what the user and the product do together to achieve said task. The use of task description is to give a clear understanding of how the system will operate when used, straining points by evaluating critical use and used for verification and validation. The list is located in the All Entities chapter (see page \pageref{tasksEntities}).

\subsection{Data model}
After elicitation a data model of all objects containing data was modeled \cite{lauren2}. The model shows the data that should be stored.
\begin{figure}[h!]
\begin{center}
\includegraphics[scale=0.5]{img/dataModel.png}
\caption{Data model.}
\end{center}
\end{figure}
\begin{description}
 \item[User] \hfill \\
The product is supposed to store all user information. Usage statistics, coupons the user owns and if user has rated the product.
 \item[Pin] \hfill \\
User and stores can be viewed as a pin. Each pin has a colour, type indicator, POI, coupons and location of the store/user.
 \item[Store] \hfill \\
The store information that should be stored in the system is the title of the store, an address of where store is located, the stores open hours, and any other information the specific franchise would want for their stores.
 \item[Coupon] \hfill \\
Each user has a list of coupons. Each coupon should have a list of stores that it's available in, what the offer is, expiration date, date limit of usage and the QR code of said coupon.
\end{description}
The data model was done as to specify data requirements. All data requirements seen in this model were specified in this model.

\subsection{Virtual window}
Virtual windows of the data that were to be shown within the application were done to give the product owners a rough idea about what information the user will have access to and to early let the product owners specify graphical user interface requirements. This was also used when producing the screenshots of the product.
\\\\
The virtual windows helped the contractors develop the screenshots of the product. It also helped out with specifying requirements of the graphical user interface. These are the virtual windows that were created:
	\begin{figure}
	\begin{center}
 \includegraphics[scale=0.2]{img/virtualwindows/AboutBookmarkView.png}
 \caption{Virtual window of bookmarks and about views.}
	\end{center}
	\end{figure}
	\begin{figure}
	\begin{center}
 \includegraphics[scale=0.2]{img/virtualwindows/CouponInfoView.png}
 \caption{Virtual window of info and coupon views.}
	\end{center}
	\end{figure}
	\begin{figure}
	\begin{center}
 \includegraphics[scale=0.2]{img/virtualwindows/MapNewsView.png}
 \caption{Virtual window of news and map views}
	\end{center}
	\end{figure}

\newpage
\subsection{Screenshots}
The screenshots were developed with the help of the virtual windows and helped the product owner to validate the graphical user interface requirements and let the contractors verify and validate the requirements. The screenshots helped further specify the graphical user interface specification as it became a clear view of the final product and what it would need to contain. For example did screenshots specify the visible radius requirement. The screenshots can be found in appendix (see page \pageref{screenshots}).


% Stores view old?

\subsection{QUPER}
When specifying the quality requirements the QUPER model was used when applicable. Many of the competitor values where estimated rather than measured. This method helped a lot in estimating reasonable targets for our quality requirements.
The program used for generating these visualizations of the QUPER model was Super QUPER.
\\\\
The comparisons is of the quality requirements Execution rigidity (see \pageref{qualityExecution}), Execution time limit (see \pageref{qualityTimeLimit}) and Startup time (see \pageref{qualityStartup}).

\begin{center}
\includegraphics[scale=0.25]{img/exRig.png}
%\caption{QUPER model of Execution Rigidity}
\includegraphics[scale=0.25]{img/exTime.png}
%\caption{QUPER model of Execution Time Limit}
\includegraphics[scale=0.25]{img/startup.png}
%\caption{QUPER model of Startup Time}
\end{center}
